Bottleneck Detector Application Programming Interface

ABSTRACT

An application programming interface may receive workload identifiers and checkpoint identifiers from which bottleneck detection may be performed. Workloads may be tracked through various checkpoints in an application and timestamps collected at each checkpoint. From these data, bottlenecks may be identified in real time or by analyzing the data in a subsequent analysis. The workloads may be processed by multiple devices which may comprise a large application. In some cases, the workloads may be processed by different devices in sequence or in a serial fashion, while in other cases workloads may be processed in parallel by different devices. The application programming interface may be part of a bottleneck detection service which may be sold on a pay-per-use model, a subscription model, or some other payment scheme.

BACKGROUND

Computer applications often have bottlenecks that may limit thethroughput or efficiency of an application. Often, bottlenecks may notbe fully appreciated when the application code is being written and mayonly be noticeable when the code may be executed under load.

The bottlenecks may be an artifact of the application design, poorprogramming technique, or may be the result of outside constraints on anapplication. When a bottleneck may be identified, a programmer may beable to investigate the bottleneck and rewrite or otherwise improve thecode to increase application performance.

SUMMARY

A bottleneck detector may analyze individual workloads processed by anapplication by logging times when the workload may be processed atdifferent checkpoints in the application. For each checkpoint, a curvefitting algorithm may be applied, and the fitted curves may be comparedbetween different checkpoints to identify bottlenecks or other poorlyperforming sections of the application. A real time implementation of adetection system may compare newly captured data points againsthistorical curves to detect a shift in the curve, which may indicate abottleneck. In some cases, the fitted curves from neighboringcheckpoints may be compared to identify sections of the application thatmay be a bottleneck. An automated system may apply one set ofcheckpoints in an application, identify an area for furtherinvestigation, and apply a second set of checkpoints in the identifiedarea. Such a system may recursively search for bottlenecks in anexecuting application.

An application programming interface may receive workload identifiersand checkpoint identifiers from which bottleneck detection may beperformed. Workloads may be tracked through various checkpoints in anapplication and timestamps collected at each checkpoint. From thesedata, bottlenecks may be identified in real time or by analyzing thedata in a subsequent analysis. The workloads may be processed bymultiple devices which may comprise a large application. In some cases,the workloads may be processed by different devices in sequence or in aserial fashion, while in other cases workloads may be processed inparallel by different devices. The application programming interface maybe part of a bottleneck detection service which may be sold on apay-per-use model, a subscription model, or some other payment scheme.

A bottleneck detector may use an iterative method to identify abottleneck with specificity. An automated checkpoint inserter may placecheckpoints in an application. When a bottleneck is detected in an areaof an application, the first set of checkpoints may be removed and a newset of checkpoints may be placed in the area of the bottleneck. Theprocess may iterate until a bottleneck may be identified with enoughspecificity to aid a developer or administrator of an application. Insome cases, the process may identify a specific function or line of codewhere a bottleneck occurs.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings,

FIG. 1 is a diagram illustration of an embodiment showing a method forperforming bottleneck analysis.

FIG. 2 is a diagram illustration of an embodiment showing a networkenvironment with devices to perform bottleneck analysis.

FIG. 3A is a diagram illustration of an example embodiment showing abacklog as a function of load for various checkpoints.

FIG. 3B is a diagram illustration of an example embodiment showing abacklog as a function of time for various checkpoints.

FIG. 3C is a diagram illustration of an example embodiment showing rawdata of workloads passing various checkpoints.

FIG. 4 is a flowchart illustration of an embodiment showing a method forcollecting data.

FIG. 5 is a flowchart illustration of an embodiment showing a method foranalyzing data in real time.

FIG. 6 is a flowchart illustration of an embodiment showing a method forautomated bottleneck detection.

FIG. 7 is a flowchart illustration of an embodiment showing a method foriterating to pinpoint a bottleneck.

DETAILED DESCRIPTION Bottleneck Detection Using Timestamps

Bottlenecks in executing programs may be identified by analyzing thetimestamps taken as workloads pass certain checkpoints. A bottleneck maybe identified when the time to execute a workload between twocheckpoints increases at a greater rate than the load increases.

A bottleneck detector may capture timestamps as workloads passcheckpoints within an application, then analyze the timestamps toidentify bottlenecks. The workloads may be any type of memory object,message, process, thread, or other application element that may beoperated upon through a sequence of operations. Throughout the course ofthe workload, various checkpoints may be placed to track the progress ofthe workload. For each workload, a sequence of timestamps may becollected for each of the checkpoints that the workload may pass.

In a lightly loaded application, each workload may typically be executedin approximately the same elapsed time. As the load increases to thepoint where a bottleneck may occur, workloads may take an increasingamount of time at a bottleneck.

In a simple analogy, workloads may be visualized as cars travelling on amultilane highway. When there is very little traffic, each car may passmile posts at approximately the same time from the previous mile post.If there was a bottleneck in the highway, due to construction or anaccident, the number of lanes may constrict, forcing the cars to slowdown through the bottleneck. In such a case, the time from one mile postto another for each car that may pass through the bottleneck mayincrease. This effect may be measured and detected as a bottleneck.

The timestamps may be taken at various locations within an application.In some cases, an application may be decorated with function calls thatmay transmit a workload identifier and capture a timestamp for eachcheckpoint. The function calls may be placed throughout an applicationto track a workload's progress through the application. In such anembodiment, the executable code for an application may be changed toinclude the checkpoint function calls. Such embodiments may make suchchanges in source code, intermediate code, binary code, or other phasesof an application.

In some embodiments, an instrumented execution environment may identifycheckpoints and set events at each checkpoint to capture timestamp data.In such embodiments, the checkpoints may be created and managed withoutchanging the executable code of an application. Such embodiments mayhave an identification system for creating and setting the checkpoints,as well as a detection and collection system that may detect thecheckpoint and collect related data.

The application may operate on a single device or across multipledevices. In a single device embodiment, the application may execute on asingle hardware platform, which may have multiple processors and variousmemory and peripheral components. In a single device embodiment, thedevice may have a clock from which timestamps may be taken.

In a multiple device application, the application may consist of similaror different software components that may operate on different devices.For example, some applications may operate in a computer cluster, whereeach device may execute a similar instance of an application to theother devices. In another example, several devices may process workloadsin series, where one device may process a workload which may be passedto another device for additional processing. In such embodiments, asynchronized clock may be used to coordinate timestamps that may begathered from multiple devices.

A bottleneck detection system may use various time series techniques forcapturing, analyzing, and displaying bottleneck information in real timeor near-real time. With each data collection event, a set of statisticalparameters may be gathered and summed, which may enable otherstatistical analyses to be performed. The statistical parameters may belightweight enough to be calculated and updated with minimal computerprocessing overhead, and a separate analysis routine may analyze thedata for bottlenecks in an offline or near-real time basis.

Application Programming Interface for Bottleneck Detection

An application programming interface may receive workload identifiersand checkpoint identifiers from applications being analyzed forbottlenecks. The application programming interface may receive and storetimestamped data. In some embodiments, the application programminginterface may analyze and display the data in real time or near-realtime. In other embodiments, a detailed analysis may be performed onhistorical data.

The application programming interface may operate in several differentarchitectures. In one architecture, a programmer may add function callswithin an application, where the function calls may communicate with anapplication programming interface locally or over a network connection.In another architecture, an execution environment may have alerts orother monitoring functions that may transmit information to theapplication programming interface when each checkpoint is reached. Insome such architectures, the execution environment may be an integrateddevelopment environment with code editors, compilers, debugging tools,and other components.

The application programming interface may operate as a programmaticgateway to accept data in real time, and an accompanying analysis andrendering engines may identify bottlenecks and may generatevisualizations of the data. In some cases, the analysis engines mayidentify bottlenecks automatically and generate an alert or otherreport. In other cases, the analysis engine may generate graphs or othervisualizations that may be displayed as data are received or using asecondary analysis.

The application programming interface may be one component of a paidservice for application developers. The service may be a subscriptionbased service, pay-per-use service, or have some other paymentmechanism.

Automatic Bottleneck Detection with Automated Checkpoint Selection

An automated bottleneck detection system may use a recursive mechanismto isolate and identify a bottleneck in an application. A first set ofcheckpoints may be used to identify a portion of an application thatcontains a bottleneck, then a second set of checkpoints may be deployedwithin the identified portion. From analysis of the second set ofcheckpoints, the location of a bottleneck may be refined. Such a processmay iterate until a bottleneck is defined with a high degree ofspecificity.

An automated bottleneck detection system may include an automatedmechanism for identifying and placing checkpoints in an application. Insome embodiments, such a mechanism may insert function calls orotherwise decorate an application in source code, intermediate code,binary code, or some other form. In some cases, an automated bottleneckdetection system may attempt to identify natural breaks or otherelements in an application into which to insert checkpoints. In somecases, an automated mechanism for inserting checkpoints may placecheckpoints at locations that may not be natural breaks.

In some cases, an automated bottleneck detection system may use a set ofpredefined checkpoint function calls that may be inserted automaticallyor inserted by a programmer. In such embodiments, the automatedbottleneck detection system may turn on a first subset of checkpointfunction calls, identify the general area of a bottleneck, then turn ona second subset of checkpoint function calls that are nearer to thebottleneck to home in on the bottleneck location.

Throughout this specification and claims, the terms “profiler”,“tracer”, and “instrumentation” are used interchangeably. These termsrefer to any mechanism that may collect data when an application isexecuted. In a classic definition, “instrumentation” may refer to stubs,hooks, or other data collection mechanisms that may be inserted intoexecutable code and thereby change the executable code, whereas“profiler” or “tracer” may classically refer to data collectionmechanisms that may not change the executable code. The use of any ofthese terms and their derivatives may implicate or imply the other. Forexample, data collection using a “tracer” may be performed usingnon-contact data collection in the classic sense of a “tracer” as wellas data collection using the classic definition of “instrumentation”where the executable code may be changed. Similarly, data collectedthrough “instrumentation” may include data collection using non-contactdata collection mechanisms.

Further, data collected through “profiling”, “tracing”, and“instrumentation” may include any type of data that may be collected,including performance related data such as processing times, throughput,performance counters, and the like. The collected data may includefunction names, parameters passed, memory object names and contents,messages passed, message contents, registry settings, register contents,error flags, interrupts, or any other parameter or other collectabledata regarding an application being traced.

Throughout this specification and claims, the term “executionenvironment” may be used to refer to any type of supporting softwareused to execute an application. An example of an execution environmentis an operating system. In some illustrations, an “executionenvironment” may be shown separately from an operating system. This maybe to illustrate a virtual machine, such as a process virtual machine,that provides various support functions for an application. In otherembodiments, a virtual machine may be a system virtual machine that mayinclude its own internal operating system and may simulate an entirecomputer system. Throughout this specification and claims, the term“execution environment” includes operating systems and other systemsthat may or may not have readily identifiable “virtual machines” orother supporting software.

Throughout this specification, like reference numbers signify the sameelements throughout the description of the figures.

In the specification and claims, references to “a processor” includemultiple processors. In some cases, a process that may be performed by“a processor” may be actually performed by multiple processors on thesame device or on different devices. For the purposes of thisspecification and claims, any reference to “a processor” shall includemultiple processors which may be on the same device or differentdevices, unless expressly specified otherwise.

When elements are referred to as being “connected” or “coupled,” theelements can be directly connected or coupled together or one or moreintervening elements may also be present. In contrast, when elements arereferred to as being “directly connected” or “directly coupled,” thereare no intervening elements present.

The subject matter may be embodied as devices, systems, methods, and/orcomputer program products. Accordingly, some or all of the subjectmatter may be embodied in hardware and/or in software (includingfirmware, resident software, micro-code, state machines, gate arrays,etc.) Furthermore, the subject matter may take the form of a computerprogram product on a computer-usable or computer-readable storage mediumhaving computer-usable or computer-readable program code embodied in themedium for use by or in connection with an instruction execution system.In the context of this document, a computer-usable or computer-readablemedium may be any medium that can contain, store, communicate,propagate, or transport the program for use by or in connection with theinstruction execution system, apparatus, or device.

The computer-usable or computer-readable medium may be, for example butnot limited to, an electronic, magnetic, optical, electromagnetic,infrared, or semiconductor system, apparatus, device, or propagationmedium. By way of example, and not limitation, computer readable mediamay comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EEPROM, flash memory or other memorytechnology, CD-ROM, digital versatile disks (DVD) or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, or any other medium which can be used tostore the desired information and which can accessed by an instructionexecution system. Note that the computer-usable or computer-readablemedium could be paper or another suitable medium upon which the programis printed, as the program can be electronically captured, via, forinstance, optical scanning of the paper or other medium, then compiled,interpreted, of otherwise processed in a suitable manner, if necessary,and then stored in a computer memory.

When the subject matter is embodied in the general context ofcomputer-executable instructions, the embodiment may comprise programmodules, executed by one or more systems, computers, or other devices.Generally, program modules include routines, programs, objects,components, data structures, etc. that perform particular tasks orimplement particular abstract data types. Typically, the functionalityof the program modules may be combined or distributed as desired invarious embodiments.

FIG. 1 is a diagram of an embodiment 100 showing a bottleneck detectionmechanism in its operational parts. Embodiment 100 is merely one exampleof a bottleneck detection system that may be performed on anapplication.

A set of workloads 102 may be executed by an application in an executionenvironment 104. The workloads may be any units of work that may betraced, tracked, or otherwise monitored on a series of checkpoints. Aseach workload 102 is executed, the various checkpoints 106, 108, 110,and 112 may capture a respective set of timestamps 114, 116, 118, and120. The timestamps may include load factors and other data.

A data collector 122 may gather and transmit the data to an analyzer124, which may generate a graph 126 or provide other output. In somecases, the analyzer 124 may produce output in real time, while in othercases, the analyzer 124 may process the various data elements aftercollection has completed.

The bottleneck detection of embodiment 100 may identify bottlenecks bymeasuring the difference in timestamps between various checkpoints foreach workload. A bottleneck may be identified when the time differencebetween two checkpoints grows for each successive workload. In such acondition, the downstream process may be processing fewer workloads thanmay be coming in, causing the bottleneck.

The workloads may be any unit of work that may be tracked through anapplication. In some cases, the unit of work may be captured in a dataitem that may be passed from one portion of executable code to another.In other cases, the unit of work may be a process, transaction, thread,or other executable or data element that may undergo transformations orchanges by several portions of an application.

In some embodiments, the workloads may be passed from one device toanother. For example, a high performance computing environment may usemessage passing to transmit workloads from one device to another. Othersystems, such as computer cluster arrangements, may use multiple devicesto handle workloads in parallel or in series.

The workloads may or may not be independent of each other. In someembodiments, the workloads may be clearly delineated and independent.Other embodiments may have workloads that may interact with each otheror are not fully independent. In many cases, a more reliable bottleneckdetection may occur with independent workloads.

At each checkpoint, a timestamp and workload identifier may be captured.In many embodiments, a load factor and other data may also be gathered.The timestamp may be a ‘wall clock’ time that may reflect the actualtime a checkpoint may have been encountered. Such a timestamp may beuseful in cases where a workload may be processed by multiple devices.

In some embodiments, the timestamp may be an elapsed time from somedesignated start time. For example, some embodiments may start a clockwhen a workload encounters a first checkpoint, then collect elapsed timefrom the first checkpoint for each subsequent checkpoint. Otherembodiments may determine elapsed time from the preceding checkpoint.

With each checkpoint and timestamp, a workload identifier may becaptured. The workload identifier may be a mechanism to link subsequentcheckpoint timestamps to each other. In some cases, a workloadidentifier may have a natural and meaningful name. In other cases, anarbitrary name may be assigned to workloads, one example of which may beto assign consecutive numbers as workload identifiers.

A load factor may be collected with the timestamp. The load factor maybe any indicator for the ‘busy-ness’ or amount of work attempting to beprocessed by a system. In some embodiments, the load factor may becollected by a different data collection mechanism and matched to thedata collected from the checkpoints by the timestamps or othermechanism. For example, a load factor may be a network traffic metricgathered from a network interface, a processor use metric collected froma hardware counter or other monitoring system.

The load factor may be implied in some embodiments. For example, a loadfactor may be inferred from the number of workload items being processedat a given time, or by the rate at which work items may be received bythe system.

The analyzer 124 may organize the data by checkpoint and may create atime series representing the time lag between a baseline time and thecheckpoint timestamp for each workload. Such a time series may beanalyzed to determine when the values grow. In a non-bottleneck steadystate, such a time series would be expected to be a flat, straight line.When a bottleneck occurs, the values in such a time series would beexpected to grow.

The growth in the time series values may be linear or non-linear,depending on the application. Some embodiments may monitor thecheckpoint data in real time and, using time series analyses, mayevaluate the data stream to determine when the data stream has deviatedfrom an expected constant value.

In many embodiments, such an analysis may take into consideration thevariance of the data. Some data sets may contain more noise than others,and the correlation coefficient or other metrics of noise may bedifferent for each application. In general, the larger the variance inthe data, the greater a deviation may be present before a bottleneck maybe identified.

FIG. 2 is a diagram of an embodiment 200 showing components that mayperform bottleneck detection. Embodiment 200 contains a device 202 thatmay be a single device in which bottleneck detection may occur, as wellas several devices that may perform bottleneck detection on a largerscale, including monitoring applications that execute over multipledevices.

A single device architecture may gather tracer data containingtimestamps gathered at various checkpoints, analyze the data, andgraphically display the data or perform bottleneck detection.

A multiple device architecture may divide different components of thedata gathering, analysis, and management functions over differentdevices. The multiple device architecture may be one way to deliver anapplication programming interface that may detect bottlenecks fromtracer data.

The diagram of FIG. 2 illustrates functional components of a system. Insome cases, the component may be a hardware component, a softwarecomponent, or a combination of hardware and software. Some of thecomponents may be application level software, while other components maybe execution environment level components. In some cases, the connectionof one component to another may be a close connection where two or morecomponents are operating on a single hardware platform. In other cases,the connections may be made over network connections spanning longdistances. Each embodiment may use different hardware, software, andinterconnection architectures to achieve the functions described.

Embodiment 200 illustrates a device 202 that may have a hardwareplatform 204 and various software components. The device 202 asillustrated represents a conventional computing device, although otherembodiments may have different configurations, architectures, orcomponents.

In many embodiments, the device 202 may be a server computer. In someembodiments, the device 202 may still also be a desktop computer, laptopcomputer, netbook computer, tablet or slate computer, wireless handset,cellular telephone, game console or any other type of computing device.

The hardware platform 204 may include a processor 208, random accessmemory 210, and nonvolatile storage 212. The hardware platform 204 mayalso include a user interface 214 and network interface 216.

The random access memory 210 may be storage that contains data objectsand executable code that can be quickly accessed by the processors 208.In many embodiments, the random access memory 210 may have a high-speedbus connecting the memory 210 to the processors 208.

The nonvolatile storage 212 may be storage that persists after thedevice 202 is shut down. The nonvolatile storage 212 may be any type ofstorage device, including hard disk, solid state memory devices,magnetic tape, optical storage, or other type of storage. Thenonvolatile storage 212 may be read only or read/write capable. In someembodiments, the nonvolatile storage 212 may be cloud based, networkstorage, or other storage that may be accessed over a networkconnection.

The user interface 214 may be any type of hardware capable of displayingoutput and receiving input from a user. In many cases, the outputdisplay may be a graphical display monitor, although output devices mayinclude lights and other visual output, audio output, kinetic actuatoroutput, as well as other output devices. Conventional input devices mayinclude keyboards and pointing devices such as a mouse, stylus,trackball, or other pointing device. Other input devices may includevarious sensors, including biometric input devices, audio and videoinput devices, and other sensors.

The network interface 216 may be any type of connection to anothercomputer. In many embodiments, the network interface 216 may be a wiredEthernet connection. Other embodiments may include wired or wirelessconnections over various communication protocols.

The software components 206 may include an operating system 218 on whichvarious software components and services may operate. An operatingsystem may provide an abstraction layer between executing routines andthe hardware components 204, and may include various routines andfunctions that communicate directly with various hardware components.

An execution environment 220 may execute an application 222 and a tracer226 may collect timestamps and other information at checkpoints in theapplication 222. The tracer 226 may store its output as tracer data 228.

The execution environment 220 may be any mechanism that may cause theapplication 222 to be executed and include a tracer 226 that may gatherdata at each checkpoint. In some embodiments, the execution environment220 may be a virtual machine such as a process virtual machine or systemvirtual machine that may be instrumented with a tracer 226. In otherembodiments, the execution environment 220 may be an integrateddevelopment environment that may include a code editor, compiler,debugging tools, and other functionality.

The tracer 226 may be any mechanism that may collect data at eachcheckpoint. In some cases, the tracer 226 may include function calls orother code that may be inserted into the executable code as binary code,intermediate code, or source code. In other cases, the tracer 226 mayoperate without modifying the executable code of the application 222.

A checkpoint inserter 224 may create checkpoints and cause the tracer226 to collect data at the various checkpoints. In some cases, thecheckpoint inserter 224 may decorate the application 222 with functioncalls or other tracer-related code. In other cases, the checkpointinserter 224 may create checkpoints that may be monitored by the tracer226 to collect the tracer data 228.

In some embodiments, the checkpoint inserter 224 may be a fullyautomated application part that may select checkpoints and cause thetracer 226 to execute at each checkpoint. In other embodiments, thecheckpoint inserter 224 may have some user interface through which ahuman programmer may select locations for checkpoints, which may beautomatically or manually inserted into an application.

A data analyzer 230 may receive the tracer data 228 to detect variousbottlenecks. In some embodiments, the output of the data analyzer 230may be transmitted to a rendering engine 232 to display graphicalresults.

In a network 234 environment, some embodiments may be deployed overmultiple devices.

A tracer manager device 236 may operate on a hardware platform 238,which may be similar to the hardware platform 204. In some cases, thevarious hardware platforms may include cloud based executionenvironments which may or may not have a notion of a computing ‘device’.

A tracer manager 240 may manage the operations of a tracing system overmultiple devices, such as applications that may be deployed on aclustered computer configuration or other multiple-device architecture.In such embodiments, the tracer manager 240 may coordinate execution ofan application, tracers on each device, as well as load generators andother components. The tracer manager 240 may also control a checkpointinserter 242 and data analyzer 244.

In some embodiments, the tracer manager 240 may operate bottleneckdetection as a paid service. In such an embodiment, customers may payfor bottleneck detection analysis using a payment manager 245, which maycharge on a subscription basis, a pay-per-use basis, or othermechanisms.

One or more execution platforms 246 may execute the application and maycollect checkpoint data. The execution platforms 246 may each have ahardware platform 248 on which an execution environment 250 may run.Each application 252 may be identical instances of the same applicationor may be different components of a larger application. The tracers 254may gather trace data when a checkpoint is reached.

A data collection device 264 may operate on a hardware platform 266 andmay contain an application programming interface 268 that may receivedata from the tracers 254 and store the tracer data 270 for analysis.The application programming interface 268 may receive data taken at eachcheckpoint occurrence, then store the data.

In some cases, the application programming interface 268 may performsome processing of the incoming data. For example, some embodiments maycreate a timestamp when a data element is received from a tracer 254. Inanother example, some embodiments may preprocess the incoming data intoa format that may be further processed by an analysis engine.

The application programming interface 268 may be used by the tracer 226that may operate on an embodiment with a single execution environment,as well as gathering data from multiple tracers 254 on multipleexecution environments.

A load generator device 258 may operate on a hardware platform 260 andmay have a load generator 262 application. The load generator 262 maycreate workloads that may be processed by an application. In some cases,such workloads may be artificial or fictitious workloads that mayexercise the application so that bottlenecks may appear in the tracerdata.

FIG. 3A is a diagram illustration of an example embodiment 300 showing agraph identifying inflection points as bottlenecks from trace data.Embodiment 300 illustrates a graph showing load on the X axis versusbacklog on the Y axis.

The backlog may indicate the amount of time that a workload took toreach a given checkpoint. Five lines 304, 306, 308, 310, and 312 areshown in the graph, and each line may represent the backlog for a givencheckpoint as a function of the load experienced by the system.

The graph of embodiment 300 may or may not reflect the sequence ofworkloads processed by an application, but instead may reflectmeasurements taken at different levels of loading. If the workload wasapplied in ever increasing amounts, the graph 300 may represent thebacklog received over time, but in many cases, data used to generate agraph such as embodiment 300 may be gathered over many cycles of high,medium, and low loads.

In a normal situation where a checkpoint does not experience abottleneck, the checkpoint lines may be horizontal lines, such as forcheckpoints 304 and 306.

At a certain amount of load, checkpoint line 308 may diverge at theinflection point 314. The inflection point 314 may identify the load atwhich a bottleneck occurred, as well as identified that the bottleneckoccurred between checkpoints 306 and 308. A programmer may be able tospot the inflection point 314 visually and investigate the bottleneck inthe code between checkpoints 306 and 308.

As the load increases, a second inflection point 316 may indicate asecond bottleneck that may occur between checkpoints 310 and 312. Again,a programmer may be able to investigate and attempt to address thebottleneck.

The graph of embodiment 300 may be created by mapping the elapsed timefor each workload measured from an initial starting point. When such ameasurement or calculation is performed, each checkpoint may beillustrated as a stacked line configuration, where the sequence ofworkflow may be from the bottom of the graph to the top.

The result of such a measurement may also yield lines that are parallelto each other. For example, checkpoint 310 remains parallel tocheckpoint 308 after the inflection point 314. This indicates that thetime between checkpoints 308 and 310 may not have changed even after thebottleneck was incurred. The rise of the checkpoint 310 may reflect thedownstream effects of the bottleneck in checkpoint 308.

In some embodiments, the infection points 314 and 316 may be identifiedthrough numerical analysis. Such numerical analysis may attempt to fit acurve to the data points, beginning with a straight line curve, andprogressing to more complex curves. When the data may not fit a straightline curve, an analysis may attempt to find an inflection point byfitting two line segments. The correlation coefficient for each curvefitting step may be used as a measure of variance in the data as well asa metric for determining when a fitted curve is a sufficient match.

The analysis of checkpoint lines may involve comparing the slope of alinear curve fitting analysis, such as linear regression. In suchanalysis, a positive change in slope from one checkpoint line to asubsequent checkpoint line may indicate a bottleneck.

FIG. 3B is a diagram illustration of an example embodiment 302 showing agraph identifying inflection points as bottlenecks from trace data.Embodiment 302 illustrates a graph showing time on the X axis versusbacklog on the Y axis. Embodiment 300 as described above represents loadon the X axis, embodiment 302 illustrates a different graph with time onthe X axis.

The backlog may indicate the amount of time that a workload took toreach a given checkpoint. Six lines 318, 320, 322, 324, 326, and 328 areshown in the graph, and each line may represent the backlog for a givencheckpoint as a function of the time.

The graph of embodiment 302 may illustrate a system's response toincreasing and decreasing loads. The amount of load is not shown in thegraph, but the effects of load may be illustrated.

As with graph 300, checkpoints 318 and 320 illustrate checkpoints whereno bottlenecks have been experienced. At inflection point 330,checkpoint 322 experienced a bottleneck that continues to build untilinflection point 332, where the bottleneck recedes until the bottleneckdissipates. While that is occurring, checkpoint 326 experiences aninflection point 334, which indicates a second bottleneck. In the graph302, the bottleneck of checkpoint 326 appears to build while thebottleneck of checkpoint 332 recedes.

FIG. 3C is a diagram illustration of an example embodiment 336 showingraw data that may be plotted on a graph. Embodiment 336 illustrates datafor multiple workloads as those workloads are received, and thetimestamps for each checkpoint for each workload.

The X axis may show datasets for individual workloads as organized bythe start time for the workload. Workloads 338, 340, 342, and 344 areillustrated with data points indicating when the workloads passedcheckpoints 346, 348, and 350. Additional workloads are also shown.

The checkpoints 346, 348, and 350 may have lines representing a best fitacross the various checkpoint data points for the workloads. From evencasual observation, the line fitted to checkpoint 346 data appears to beflat and does not change over time, while the line fitted to checkpoint348 appears to rise, and the line fitted to checkpoint 350 appears torise even further.

The difference between the slopes of the lines for checkpoint 346 and348 may indicate that a bottleneck exists between checkpoints 346 and348, and that the bottleneck grows as time increases. A similarsituation may also be present between checkpoints 348 and 350. In somedatasets, workloads may be processed in irregular patterns. In theexample of embodiment 336, workloads 338 and 340 may be received with atime distance 352, while workloads 342 and 344 may have been receivedwith a shorter time distance 354.

FIG. 4 is a flowchart illustration of an embodiment 400 showing a methodfor gathering tracer data. The operations of embodiment 400 mayillustrate one method that may be performed by the tracers 226 or 254 ofembodiment 200.

Other embodiments may use different sequencing, additional or fewersteps, and different nomenclature or terminology to accomplish similarfunctions. In some embodiments, various operations or set of operationsmay be performed in parallel with other operations, either in asynchronous or asynchronous manner. The steps selected here were chosento illustrate some principles of operations in a simplified form.

A tracer may operate in an execution environment to gather timestamp andother data at each checkpoint. In some cases, the checkpoint may beidentified by function calls or other markers in the executable code. Inother cases, a checkpoint may be an event, executable code component, orother identifiable element of an executing code.

An execution environment may receive workloads for an application inblock 402. For each workload in block 404, the workload may be executedto a first checkpoint in block 406 and timestamp and other data may betaken in block 408. The workload may be executed to a second checkpointin block 410 and a second timestamp and other data may be taken in block412. Similarly, the workload may be executed to a third checkpoint inblock 414 and a third timestamp and other data may be taken in block416. The sequence of execution to a checkpoint and collecting data maycontinue until the workload has finished being processed.

The execution environment may process many workloads in the manner ofblocks 406 through 416. In many cases, multiple workloads may beprogressing through an application at once.

After collecting all the timestamps and other data, the data may bestored in block 418 and analysis may be performed on the data in block420.

FIG. 5 is a flowchart illustration of an embodiment 500 showing a methodfor analyzing tracer data in real time. The operations of embodiment 500may illustrate one method that may be performed by the data analyzers230 or 244 of embodiment 200.

Other embodiments may use different sequencing, additional or fewersteps, and different nomenclature or terminology to accomplish similarfunctions. In some embodiments, various operations or set of operationsmay be performed in parallel with other operations, either in asynchronous or asynchronous manner. The steps selected here were chosento illustrate some principles of operations in a simplified form.

Embodiment 500 illustrates one method for analyzing tracer data in realtime or near-real time. A timestamp may be received in block 502 and aworkload level or other data may be determined in block 504. Thetimestamp may include a workload identifier and checkpoint identifier.In some embodiments, only the workload identifier and checkpointidentifier may be received, and the timestamp may be determined afterreceiving the data.

In the example of embodiment 500, the timestamp may represent a value inthe Y axis and the workload level may represent a value in the X axis,which may be used to generate a graph such as may be shown in embodiment300.

In the example of embodiment 302 where the X axis represents time, theworkload level may not be collected in block 504.

A set of time series statistics may be updated in block 506. The timeseries statistics may be any type of statistics from which furtheranalyses may be performed. In a simple example of such statistics, thetime series statistics may reduce or compress the full trace of X and Yvalues to the sum of all X values, sum of all Y values, the sum of thesquare of X values, the sum of the square of Y values, the sum of theproduct of XY, and the number of samples. From these time series data,linear regression may be performed on the dataset to generate a slopeand intercept as well as a correlation coefficient.

In such an embodiment, an analysis may be performed that compares theslope of adjacent checkpoint datasets. When the slope of a latercheckpoint diverges or increases from a previous checkpoint, abottleneck may be identified.

After updating the time series statistics in block 506, the process mayloop back to block 502 to process another incoming dataset. Such a loopmay be performed relatively quickly, and the remaining blocks 508 and510 may be performed either offline or in a different thread or processso that the data collection of blocks 502 through 506 may proceedwithout delay.

In block 508, new values for a visualization graph may be determined andthe visualization may be rendered in block 510. In many cases, thecalculation and rendering operations of blocks 508 and 510 may consume arelatively large amount of resources than blocks 502 through 506, thusblocks 508 and 510 may be separated.

FIG. 6 is a flowchart illustration of an embodiment 600 showing a methodfor detecting bottlenecks from tracer data. The operations of embodiment600 may illustrate one method that may be performed by the dataanalyzers 230 or 244 of embodiment 200.

Other embodiments may use different sequencing, additional or fewersteps, and different nomenclature or terminology to accomplish similarfunctions. In some embodiments, various operations or set of operationsmay be performed in parallel with other operations, either in asynchronous or asynchronous manner. The steps selected here were chosento illustrate some principles of operations in a simplified form.

Embodiment 600 illustrates a method that analyzes data gathered in aprocess such as that of embodiment 400 and detects bottlenecks.

Historical data may be received in block 602. The data may be analyzedfor each checkpoint in block 604. For a given checkpoint, the data foreach workload may be analyzed in block 606.

For each workload, a time difference may be calculated from a previouscheckpoint in block 608. The time difference may be calculated from theimmediately preceding checkpoint in some embodiments, while otherembodiments may calculate the time difference from a start time for theworkload.

In block 610, a workload factor may be identified for the timecorresponding to the timestamp of the current workload at the currentcheckpoint. The workload factor may be used in embodiments where theanalysis may be performed on historical data. In an embodiment such asembodiment 302 where the X axis of a graph may be time, a workloadfactor may not be used.

After preparing the data in blocks 606 through 610, a curve fittinganalysis may be performed. In some cases, the curve fitting may beperformed against a load factor, while in other cases, the curve fittingmay be performed against time.

An analysis of the fitted curve may be performed in block 614 for anyanomalies. An anomaly may be a very high correlation coefficient in alinear curve fitting attempt, an inflection point in a more complicatedcurve fitting method, or some other indicator that that data may not beadequately represented by a line. When an anomaly is not detected inblock 616, the checkpoint curve may not reveal a bottleneck. When ananomaly is detected in block 616, the location may be labeled as abottleneck.

The analysis of blocks 604 through 618 may analyze the data at eachcheckpoint to attempt to identify a bottleneck. The analysis from blocks620 through 630 may attempt to identify bottlenecks by comparing twocheckpoint data streams to each other.

For each checkpoint in block 620, the curve of the current checkpoint iscompared to the curve of the previous, upstream checkpoint in block 622.The comparison in block 622 may compare the slope of one checkpointdataset to the slope of a second checkpoint dataset. In suchembodiments, a diverging slope may indicate that a later checkpointcontains a bottleneck with respect to the previous checkpoint.

In other embodiments where the curve fitting is a more complexexpression, the comparison may detect whether both checkpoint curves areoffset or parallel to each other. Diverging data sets may indicate thatthe later checkpoint may contain a bottleneck with respect to theearlier checkpoint.

When the difference between the two curves is not significant in block624, the current checkpoint may not be considered as a bottleneck inblock 626.

When the difference between the two curves is significant in block 624,the current checkpoint may be considered to have a bottleneck in block628, and the checkpoint may be labeled as a bottleneck in block 630.

FIG. 7 is a flowchart illustration of an embodiment 700 showing aniterative method for detecting bottlenecks from a running application.The operations of embodiment 700 may illustrate one method that may beperformed by the tracer manager 240 of embodiment 200.

Other embodiments may use different sequencing, additional or fewersteps, and different nomenclature or terminology to accomplish similarfunctions. In some embodiments, various operations or set of operationsmay be performed in parallel with other operations, either in asynchronous or asynchronous manner. The steps selected here were chosento illustrate some principles of operations in a simplified form.

Embodiment 700 is an example of an iterative method to identify abottleneck with a high degree of specificity. Embodiment 700 is anexample of a method by which a relatively small number of checkpointsmay be spread through an application, and when a bottleneck is detectedbetween two of the checkpoints, another set of checkpoints may be placedin the area of the application between the checkpoints and the processmay be repeated.

The method of embodiment 700 may iterate repeatedly to find a bottleneckwith a high degree of specificity. Such specificity may be at the levelof a single function call or even a specific line of an application,depending on the embodiment.

In block 702, an application may be received. The application may beanalyzed in block 704 to identify checkpoints, and the checkpoints maybe added to the application in block 706.

In some embodiments, the checkpoints in block 704 may be ‘natural’locations in an application where a checkpoint may be relevant. Examplesof such locations may be at function calls or other points within theapplication. In other embodiments, the checkpoints may be identified bymerely spacing the checkpoints within the application code by apredefined number of instruction lines or some other method.

The application may begin execution in block 708 and data may start tobe collected. In block 710, a load may be applied, which may be anartificial load or a natural load in a production system.

The checkpoint data may be analyzed to identify a bottleneck in block712. In some cases, the application may be driven with ever increasingloads until a bottleneck becomes apparent.

If the bottleneck is identified in block 712 but the bottleneck is notidentified with enough specificity in block 714, an additional set ofcheckpoints may be determined in block 718 and added to the applicationin block 720. The older checkpoints may be removed or turned off inblock 722, and the process may return to block 708 to iterate again.

The iterations may continue with smaller and smaller spacing betweencheckpoints until the bottleneck is defined with sufficient specificityin block 714, at which point the iterations may stop and the bottleneckmay be identified for the developer in block 716.

The foregoing description of the subject matter has been presented forpurposes of illustration and description. It is not intended to beexhaustive or to limit the subject matter to the precise form disclosed,and other modifications and variations may be possible in light of theabove teachings. The embodiment was chosen and described in order tobest explain the principles of the invention and its practicalapplication to thereby enable others skilled in the art to best utilizethe invention in various embodiments and various modifications as aresuited to the particular use contemplated. It is intended that theappended claims be construed to include other alternative embodimentsexcept insofar as limited by the prior art.

What is claimed is:
 1. A system comprising: a processor; a traceroperating on said processor, said tracer that: listens for a startworkload call on an interface and logs said start workload call; listensfor a checkpoint call, determines a workload for said checkpoint call,and logs said checkpoint call with a timestamp and a checkpointidentifier; a data analyzer that: creates a first curve representingsaid checkpoint calls for a first checkpoint; and identifies anabnormality from said first curve, said abnormality being identifiedfrom at least one of said checkpoint calls that deviates from said firstcurve.
 2. The system of claim 1, said tracer that further: returns aworkload identifier in response to said start workload call.
 3. Thesystem of claim 2, said tracer that further: receives a workloadidentifier with said checkpoint call.
 4. The system of claim 3, saidtimestamp being transmitted with said checkpoint call.
 5. The system ofclaim 3, said timestamp being determined when said checkpoint call isreceived.
 6. The system of claim 2, said tracer that further: creates asecond curve representing said checkpoint calls for a second checkpoint;and identifies said abnormality by comparing said first curve to saidsecond curve, said at least one of said checkpoint calls being containedin said second curve.
 7. The system of claim 6, said first curve havinga different slope from said second curve.
 8. The system of claim 6, saidfirst curve having a different correlation coefficient than said secondcurve.
 9. The system of claim 1, said first curve being a linear curve.10. The system of claim 1, said first curve being a polynomial curve.11. The system of claim 1, said timestamp being an incremental time froma beginning time.
 12. The system of claim 11, said beginning time beingdefined at said start workload call.
 13. The system of claim 12, saidbeginning time being a timestamp transmitted by a calling routine. 14.The system of claim 13, said beginning time being determined by saiddata listener.
 15. The system of claim 11, said beginning time being atime defined by a previous checkpoint call.
 16. The system of claim 1,said first curve correlating said timestamp and a load factor.
 17. Thesystem of claim 16, said load factor being received in said workloadcall.
 18. The system of claim 16, said load factor being received insaid checkpoint call.
 19. The system of claim 16, said load factor beingreceived from an external source.
 20. The system of claim 19, said loadfactor being received as a data stream comprising timestamps.